Support Lelo F1s V3 as Harmony protocol - #920

Independent confirmation: I have an F1S V3 running here (Windows 11, Intel AX210, Intiface Central 3.1.1+43).

Commands land once they go to 0000fff2, so your endpoint conclusion is right.
I got there with a user config putting F1SV3 under lelo-harmony, which is the same two characteristics you reach through generic0 and txvibrate.
test_lelo_f1sv3.yaml matches what I see on the wire.

A few things from reading the diff:

1. lelo-f1sv3.yml uses 36adf7ce-98bf-4fad-b916-b44d20a5d9e1 for both defaults.id and configurations[0].id. load_user_config resolves base_id with find(|x| x.1.id() == base_id) over a HashMap, so two definitions sharing an id make that lookup order dependent. Keeping the old id on the configuration is the right half to keep, since existing user configs point at it, so the defaults block is the one that needs a new UUID.

2. The defaults features reuse 90bd67a5-4601-4c49-97bb-0845ab7011ba and 05fc758b-a3fe-4156-b3ae-9cdcb9ae95c6, which are still lelo-f1sv2's. Two protocols now ship the same feature UUIDs.

3. With smoothing on, a zero speed returns no command and schedules the write 800 ms later, and the task swallows failures with let _ =. An explicit StopDeviceCmd then doesn't stop the device for up to 800 ms, which is more than "smoothing" suggests to whoever turns it on.

4. vibrate_smoothing_* goes onto the generic ServerDeviceDefinition and the published schema, and only lelo_harmony.rs reads it. As its own PR it stands alone, and what's left here is a config move plus a small handler change, which is a far easier merge.

5. f1sv3_harmony() is gated on protocol_variant == "f1sv3", and no shipped YAML sets protocol_variant outside vorze-sa.yml, so nothing reaches it unless a user writes the variant by hand. The use_harmony branch in lelof1sv2.rs is fine by the way, txvibrate is fff2 in that map too.

6. lelo_harmony.rs and lelof1sv2.rs collapse the repo's one-import-per-line style. rustfmt.toml sets imports_layout = "HorizontalVertical", stable cargo fmt ignores it silently, and the CI fmt check is continue-on-error: true so it won't catch it. cargo +nightly fmt should take that churn back out of the diff.

7. Minor: in maybe_defer_stop, let state = self.state.clone() shadows the MutexGuard of the same name, which stays alive to the end of the function. Fine today because the spawned task sleeps first.

For @qdot rather than for this PR: adding F1SV3 to lelo-harmony.yml with tx: 0000fff2 and whitelist: 00000a11 fixes the device with no Rust at all, since LeloHarmonyInitializer already runs the same handshake on Endpoint::Whitelist, which that map resolves to 00000a11.
That's the version I ran on hardware. It loses the separate protocol name and the smoothing knob, so it's a trade either way.